Developer CD Series 1993…ch: Other People's Memory/ADC Developer CD (1993-03) (''Other People's Memory'')_iso/Dev.CD Mar 93.iso/Development Platforms/CSMP Digests/csmp-v1-005.txt

Text File | 1992-11-18 | 53.0 KB | 1,691 lines | [TEXT/MPS ]

C.S.M.P. Digest             Sun, 08 Mar 92       Volume 1 : Issue 5

Today's Topics:

    Orphan virus?
    68040 Caches...Flush Opcode?
    What is the latest version of Sourcebug?
    Changes for C 5.0 for Mac. Prog. Primer
    Think C 5.0 Changes for Vol II Mac C Primer
    Multi-thread packages
    MacApp: IsObject isn't safe!
    Disabling all interrupts via MacOS-routine ?
    !Weird Behavior in Finder's "Get Info" Windows
    SPHIGS for Mac
    Format of icm#, icm4, icm8 icon resources
    CacheOut
    Old (strange) finder icon masks


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac directory on ftp.cs.uoregon.edu.
This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Andrew H Goodale)
Subject: Orphan virus?
Date: 28 Jan 92 16:34:01 GMT
Organization: University of Pennsylvania


    My friend thinks he has discovered a new virus (unfortunately).  He downloads many things from local BBS's.  One day when running Norton's speed disk he found that some of his empty space had now become part of an "unknown" type of file.  Under Speed Disk's color coding, the areas were black and highly fragmented.  With the magnifying glass, he looked on the black parts and the text "Orphan ??" appeared.
    Has anyone heard of this?  It appears to effect only free space, and not files because neither SAM nor Disinfectant 2.5.1 found any viruses.  Any help
would be greatly appreciated.

                        - Andrew G.

[e-mail]



- -------------------------

From: [e-mail] (Russell S. Finn)
Subject:  Orphan virus?
Date: 29 Jan 92 23:24:14 GMT
Organization: MIT Laboratory for Computer Science

In article <[e-mail]>, [e-mail] (Andrew H Goodale) writes:
|>     My friend thinks he has discovered a new virus
|> (unfortunately).  He downloads many things from local BBS's.  One
|> day when running Norton's speed disk he found that some of his
|> empty space had now become part of an "unknown" type of file.
|> Under Speed Disk's color coding, the areas were black and highly
|> fragmented.  With the magnifying glass, he looked on the black
|> parts and the text "Orphan ??" appeared.      Has anyone heard of
|> this?  It appears to effect only free space, and not files because
|> neither SAM nor Disinfectant 2.5.1 found any viruses.

Please don't take this personally, Andrew, but:

I WISH PEOPLE WOULD STOP ASSUMING THAT EVERY LITTLE ODD THING ON THEIR
MACINTOSH IS CAUSED BY A VIRUS!

There haven't been any new strains of viruses on the Macintosh in
quite some time; furthermore, the people who have taken on the
responsibility of looking out for such things (like Chris Johnson and
John Norstad; thanks, guys) do such a good job that any future viral
outbreaks are likely to be well contained.

Now admittedly it's smart to be on the safe side, particularly if one
is doing a lot of downloading; but on the other hand, if neither SAM
nor Disinfectant reported anything, why assume it's a virus?

Particularly when there's a simpler explanation:  it sounds like the
catalog on your hard disk has been corrupted in such a way that some
blocks are marked as allocated, even though they're not part of any
file.  Such blocks are commonly called "orphaned" blocks.  I'd be very
surprised if the Norton manual didn't explain this somewhere (you *do*
have the manual, right?).

This is exactly the type of problem that Disk First Aid was designed
to fix; probably some portion of the Norton Utilities will fix it, too
(I don't use it myself).

I apologize if I come across too strongly, but this one was the
proverbial last straw.  (Would whoever's working on the FAQ list
include a section on this, please?)

-- Russell S. Finn
[e-mail]



- -------------------------

From: [e-mail] (Andrew H Goodale)
Subject:  Orphan virus?
Date: 30 Jan 92 00:48:00 GMT
Organization: University of Pennsylvania

All right, I should have known better.  If this ever happens again, I'm
going to respect the opinions of SAM and Disinfectant.  That was my bad. Also,
I *don't* have the manual to Norton Utilities because I don't own it.  This was my friends IIcx; he owns Norton Utilities and didn't bother to read his manual  Sorry to have inconveienced anyone.  In the future, I won't jmp to
conclusions. :)
                        - Andrew G.

[e-mail]
Sig, sig.  Where's my sig?



---------------------------

From: [e-mail] (Michael Reed)
Subject: 68040 Caches...Flush Opcode?
Organization: Cornell Theory Center
Date: Tue, 28 Jan 1992 18:04:54 GMT

Add yet another question to the 68040 list...Is there an opcode to force a flushing of the caches?  It could be handy (to say the least) in these situations.  Then if you had to (for some unknown reason :->) to write self-modifying code, at least you could ensure that it will work properly.

-Michael G. Reed



- -------------------------

From: [e-mail] (David Temkin)
Subject:  68040 Caches...Flush Opcode?
Date: 28 Jan 92 21:48:15 GMT
Organization: EDS Corp.


In article <[e-mail]>, [e-mail] (Michael Reed) writes:
>
> Add yet another question to the 68040 list...Is there an opcode to force a flushing of the caches?  It could be handy (to say the least) in these situations.  Then if you had to (for some unknown reason :->) to write self-modifying code, at least you could ensure that it will work properly.
>
> -Michael G. Reed
>
>

There may be an opcode to do this, but the Apple-certified
method involves the use of a trap. To flush both the data
cache and the instruction cache, I've tried this code:

    if (TrapAvailable(_HWPriv)) {
        FlushDataCache();
        FlushInstructionCache();
        }

TrapAvailable() is my own. The other stuff is OS stuff, and
is available on 68030 and 040 machines. I believe that this is how the
tech note says to do this.

BUT THERE'S A PROBLEM. Perhaps I'm overlooking something and someone
can clear up the difficulty. I run the above code immediately after swapping
a set of jump table entries with another set of jump table entries.
This has the effect of causing subsequent calls to the first set of
functions to call functions from the second set, and it works quite reliably
on every 68020- and 68030-based Mac I've tried it on.

But it turns  out, if you think about it, that modifying jump table entries
constitutes self-modifying code, so I inserted the above code to fix
potential problems arising from the instruction cache.

Still, the problem remains. I don't have access to a Quadra, but friends who
do tell me that the program crashes unpredictably on that machine if the
configuration is such that the jump table entries need to be swapped (that
is, if the machine is running in color).

Is there something wrong with the above code, or is the more general
strategy somehow flawed?

Thanks,

David Temkin
[e-mail]



- -------------------------

From: [e-mail] (Matthias Ulrich Neeracher)
Subject:  68040 Caches...Flush Opcode?
Date: 29 Jan 92 14:27:53 GMT
Organization: Integrated Systems Laboratory, ETH, Zurich

In article <[e-mail]> [e-mail] (David Temkin) writes:
>There may be an opcode to do this, but the Apple-certified
>method involves the use of a trap. To flush both the data
>cache and the instruction cache, I've tried this code:
>
>    if (TrapAvailable(_HWPriv)) {
>        FlushDataCache();
>        FlushInstructionCache();
>        }
>
>TrapAvailable() is my own. The other stuff is OS stuff, and
>is available on 68030 and 040 machines. I believe that this is how the
>tech note says to do this.
>
>BUT THERE'S A PROBLEM. Perhaps I'm overlooking something and someone
>can clear up the difficulty. I run the above code immediately after swapping
>a set of jump table entries with another set of jump table entries.
>This has the effect of causing subsequent calls to the first set of
>functions to call functions from the second set, and it works quite reliably
>on every 68020- and 68030-based Mac I've tried it on.
>
>But it turns  out, if you think about it, that modifying jump table entries
>constitutes self-modifying code, so I inserted the above code to fix
>potential problems arising from the instruction cache.
>
>Still, the problem remains. I don't have access to a Quadra, but friends who
>do tell me that the program crashes unpredictably on that machine if the
>configuration is such that the jump table entries need to be swapped (that
>is, if the machine is running in color).
>
>Is there something wrong with the above code, or is the more general
>strategy somehow flawed?

A problem might occur if you use the jump table between the swapping of the
entries and the end of the flushing, for example if one of the three routines
above needs glue code from another segment.

Try installing the new jump table entries with _BlockMove, which automagically
flushes the caches, maybe this works.

Matthias

- ---
Matthias Neeracher                                      [e-mail]
 `We say "gestalt" when things combine to act in ways we can't explain'
                             -- Marvin Minsky, _The Society Of Mind_



---------------------------

From: [e-mail] (Matt Weiser)
Subject: What is the latest version of Sourcebug?
Date: 28 Jan 92 20:56:40 GMT
Organization: Martin Marietta WIS

Title says it all.  Is SourceBug released yet? (I was given a beta
version in a class.)

Thanks
Matt



- -------------------------

From: [e-mail] (Mark Lanett)
Subject:  What is the latest version of Sourcebug?
Date: 28 Jan 92 21:54:35 GMT
Organization: University of Illinois at Urbana

[e-mail] (Matt Weiser) writes:

>Title says it all.  Is SourceBug released yet? (I was given a beta
>version in a class.)

>Thanks
The version off of ETO 5 (6 is due Real Soon Now) has 1.0b4, which is
faster than 1.0b1 but doesn't have any more features.
--
Mark Lanett                                                   [e-mail]
Software Tools Group, NCSA, University of Illinois at Urbana-Champaign



- -------------------------

From: [e-mail] (Tom Santos)
Subject:  What is the latest version of Sourcebug?
Date: 29 Jan 92 09:14:37 GMT
Organization: The TeleSoft BBS and Public Access Unix, [phone]

[e-mail] (Mark Lanett) writes:

> [e-mail] (Matt Weiser) writes:
>
> >Title says it all.  Is SourceBug released yet? (I was given a beta
> >version in a class.)
>
> >Thanks
> The version off of ETO 5 (6 is due Real Soon Now) has 1.0b4, which is
> faster than 1.0b1 but doesn't have any more features.
> --
> Mark Lanett                                                   [e-mail]
> Software Tools Group, NCSA, University of Illinois at Urbana-Champaign
I have 1.0b4... you are right about it not having any more features.  In
fact, they don't plan on displaying arrays anytime in the near future.  If
you want it to display an object decently, you MUST make it a Pascal
Object.

Beware of it going into MacsBug and saying "fPatch != 0"...  It says that
every once-in-a-while and that ensures an up-coming bomb...

Tom


--
Tom Santos ([e-mail])



---------------------------

From: [e-mail] (Jim Cook)
Subject: Changes for C 5.0 for Mac. Prog. Primer
Date: 28 Jan 92 22:50:57 GMT
Organization: Prime Computer, Inc.

At least one person has requested from me the changes to programs in
Mark & Reed's Macintosh Programming Primer, Vol I, to allow the programs
that were originally composed with Think C version 4.0 to run under
Think C version 5.0.

The following list of changes were posted on America On-Line (AOL).
If you have questions, write the author as I'm only the messanger.

Jim
- ---------------------------------------------------------------------------
Dear Mac C Primer (Volume I) reader:

With the introduction of a new version of THINK C (v5.0), you'll need to make a
few changes in your  source code to maintain compatibility:

EventTutor:
1) (p. 115) Change #define of MOVE_TO_FRONT from
            -1L
    to
            (WindowPtr)-1L

2) (p. 118) Change 2 occurences of BeginUpdate( gTheEvent.message ) to
            BeginUpdate( (WindowPtr)gTheEvent.message )

3) (p. 118-119) Change 2 occurences of EndUpdate( gTheEvent.message ) to
            EndUpdate( (WindowPtr)gTheEvent.message )

4) (p. 119) Change DrawGrowIcon( gTheEvent.message ) to
            DrawGrowIcon( (WindowPtr)gTheEvent.message )

5) (p. 118) Change Call of DrawMyPicture( gTheEvent.message, gPictureHandle );
            to DrawMyPicture( (WindowPtr)gTheEvent.message, gPictureHandle );


Flying Line:
1) (p. 92) Change #define of MOVE_TO_FRONT from
            -1L
    to
            (WindowPtr)-1L


Hello2:
1) (p. 63) Change #define of MOVE_TO_FRONT from
            -1L
    to
            (WindowPtr)-1L


Mondrian:
1) (p. 74) Change #define of MOVE_TO_FRONT from
            -1L
    to
            (WindowPtr)-1L


Pager:
1) (p. 333) Change #define of MOVE_TO_FRONT from
            -1L
    to
            (WindowPtr)-1L

2) (p. 335) Change BeginUpdate( gTheEvent.message ) to
            BeginUpdate( (WindowPtr)gTheEvent.message )

3) (p. 335) Change DrawControls( gTheEvent.message ); to
            DrawControls( (WindowPtr)gTheEvent.message );

4) (p. 335) Change UpdateMyWindow( gTheEvent.message ); to
            UpdateMyWindow( (WindowPtr)gTheEvent.message );

5) (p. 335) Change EndUpdate( gTheEvent.message ) to
            EndUpdate( (WindowPtr)gTheEvent.message )


PrintPICT:
1) (p. 316) Change #include from "PrintMgr.h" to "PrintTraps.h"


Reminder:
1) (p. 229) Change #define of MOVE_TO_FRONT from
            -1L
    to
            (WindowPtr)-1L

2) (p. 240) Change 2 occurances of nmSIcon to nmIcon

3) (p. 229) Add the lines:
                     #include <Packages.h>
                     #include <Dialogs.h>
            to the very beginning of the program.



ShowClip:
1) (p. 300) Change #define of MOVE_TO_FRONT from
            -1L
    to
            (WindowPtr)-1L

2) (p. 302) Change call of CenterPict( clipHandle, &myRect );
    to CenterPict( (PicHandle)clipHandle, &myRect );


ShowPICT:
1) (p. 86) Change #define of MOVE_TO_FRONT from
            -1L
    to
            (WindowPtr)-1L


Sounder:
1) (p. 350) Add this line before the first #define:

#include <Sound.h>

2)  Optional:  Use the functions CountResources() and GetIndResource() to play
all available 'snd ' resources.  CountResources( 'snd ' ) will return the
number
of 'snd 's available in all open resource forks.  Use this value to create a
loop around calls to GetIndResource( 'snd ', i ) and SndPlay().


Timer:
1) (p. 163) Add this line before the first #define:
        #include "Packages.h"

2) (p. 163) Change #define of MOVE_TO_FRONT from
            -1
    to
            (WindowPtr)-1L

3) (p. 166) Change BeginUpdate( gTheEvent.message ) to
            BeginUpdate( (WindowPtr)gTheEvent.message )

4) (p. 166) Change EndUpdate( gTheEvent.message ) to
            EndUpdate( (WindowPtr)gTheEvent.message )


WindowMaker:
1) (p. 274) Change #define of MOVE_TO_FRONT from
            -1
    to
            (WindowPtr)-1

2) (p. 277) Change if (!IsDAWindow( gTheEvent.message ) ) to
            if (!IsDAWindow( (WindowPtr)gTheEvent.message ) )

3) (p. 277) Change SetPort( gTheEvent.message );
    to SetPort( (WindowPtr)gTheEvent.message );

4) (p. 277) Change BeginUpdate( gTheEvent.message ) to
            BeginUpdate( (WindowPtr)gTheEvent.message )

5) (p. 277) Change EndUpdate( gTheEvent.message ) to
            EndUpdate( (WindowPtr)gTheEvent.message )

6) Change DrawMyPicture( gMyPicture, gTheEvent.message );
    to DrawMyPicture( gMyPicture, (WindowPtr)gTheEvent.message );


Zinger:
1) (p. 183) Change #define of MOVE_TO_FRONT from
            -1L
    to
            (WindowPtr)-1L

2) (p. 186) Change BeginUpdate( gTheEvent.message ) to
            BeginUpdate( (WindowPtr)gTheEvent.message )

3) (p. 186) Change EndUpdate( gTheEvent.message ) to
            EndUpdate( (WindowPtr)gTheEvent.message )




- -------------------------

From: [e-mail]
Subject:  Changes for C 5.0 for Mac. Prog. Primer
Date: 30 Jan 92 10:58:46 GMT
Organization: University of Geneva, Switzerland

> At least one person has requested from me the changes to programs in
> Mark & Reed's Macintosh Programming Primer, Vol I, to allow the programs
> that were originally composed with Think C version 4.0 to run under
> Think C version 5.0.


Addison Wesley just released "Macintosh C Programming Primer Volume I,
Second Edition". It is now compatible with last versions of Think C and
with System 7!

Steve Jordi,
Dpt Of Geophysics
University of Geneva
Switzerland
[e-mail]



---------------------------

From: [e-mail] (Jim Cook)
Subject: Think C 5.0 Changes for Vol II Mac C Primer
Date: 28 Jan 92 23:13:45 GMT
Organization: Prime Computer, Inc.

Because someone asked, I'm also published the changes for Vol II of the
Macintosh Programming Primer.  The primer was published based on Think 4.0.
The following will allow you to run the programs under Think 5.0.
Send any questions to the book's author - I'm just the messanger!

Jim
<[e-mail]>

- -------------------------------------------------------------------------

Dear Mac C Primer (Volume II) reader,

With the introduction of a new version of THINK C (v5.0), you'll need to make
some changes in your  source code to maintain compatibility:

cdev.c:
1) (p. 67) Insert line, just after the last #define:
        short    FindFontNumber();

Tester.c:
1) (p. 95) Replace #define MOVE_TO_FRONT from
        -1L
    to
        (WindowPtr)-1L

2) (p. 97) Change BeginUpdate( gTheEvent.message ) to
            BeginUpdate( (WindowPtr)gTheEvent.message )

3) (p. 97) Change EndUpdate( gTheEvent.message ) to
            EndUpdate( (WindowPtr)gTheEvent.message )

DLOG.c:
1) (p. 111) Replace #define MOVE_TO_FRONT from
        -1L
    to
        (WindowPtr)-1L

ColorInfo.c:
1) (p. 136) Replace the line:
        #include "ColorToolbox.h"
    with
        #include "Picker.h"

Palette.c:
1) (p. 153) Replace the line:
        #include "ColorToolbox.h"
    with the two lines:
        #include "Palettes.h"
        #include "Picker.h"

2) (p. 153) Replace #define MOVE_TO_FRONT from
        -1L
    to
        (WindowPtr)-1L

ColorTutor.c:
1) (p. 171) Replace the line:
        #include "ColorToolbox.h"
    with the two lines:
        #include "Palettes.h"
        #include "Picker.h"

2) (p. 171) Replace #define MOVE_TO_FRONT from
        -1L
    to
        (WindowPtr)-1L

GWorld.c:
1) (p. 203) Replace the two lines:
        #include "ColorToolbox.h"
        #include "QuickDraw32Bit.h"
    with the two lines:
        #include "Picker.h"
        #include "QDOffscreen.h"

2) (p. 203) Replace #define MOVE_TO_FRONT from
        -1L
    to
        (WindowPtr)-1L

FormEdit.c:
1) (p. 244) Replace #define MOVE_TO_FRONT from
        -1L
    to
        (WindowPtr)-1L

2) (p. 251) In the function DoTEKey(), replace the line:
        tempStr[ i+1 ] = (*text)[ i ];
    with the line:
        tempStr[ i+1 ] = (*(char **)text)[ i ];

3) (p. 257) In the function HandleEditChoice(), replace the line:
        tempStr[ i+1 ] = (*text)[ i ];
    with the line:
        tempStr[ i+1 ] = (*(char **)text)[ i ];

4) (p. 266) In the function NewClikLoop(), replace the declaration:
        int            amount;
    with the line:
        short            amount;

Starter. :
1) Make a copy of the "Starter Folder" found in the "TCL 1.1 Demos" folder in
your "Development" folder.  Next, copy the following files from your old
"MyStarter" folder into this new folder:
        - CDragPane.c
        - CDragPane.h
        - CMouse.c
        - CMouse.h
        - CStarterDoc.c
        - CStarterDoc.h
        - CStarterPane.c
        - CStarterPane.h
        - Starter.c
    You should be copying 9 files, replacing their counterparts in the new
    folder.  Do NOT copy the files CStarterApp.c and CStarterApp.h!!!!!
    Start up THINK C by double-clicking the file Starter.  in this new folder.

2) Select Add... from the Source menu and add the files CDragPane.c and
CMouse.c
to the project.  Make sure you add the two files to the first segment in the
project window.  To select the first segment, click on the file name
CStarterApp.c (in the project window) before you select Add...

3) Select Options... from the Edit menu.
    - Select "Language Settings" from the popup menu.
    - Make sure that the "Language Extensions" check box is checked.
    - Select the "THINK C + Objects" radio button.
    - Make sure the "Strict Prototype Enforcement" check box is checked.
    - Select the "Infer Prototypes" radio button.

4) Edit each of the functions in the files CDragPane.c, CMouse.c, and
CStarterPane.c.  Change each function's parameter declarations from the old
style to the new style of parameter declaration.  Make sure you edit every
single function!!!  Old style declarations look like this:
        void CDragPane::DoClick( hitPt, modifierKeys, when )
        Point        hitPt;
        short        modifierKeys;
        long        when;
        {
        }
    New style declarations look like this:
        void CDragPane::DoClick( Point hitPt, short modifierKeys, long when )
        {
        }

5) (p. 348) In the file CDragPane.c, in the function IDragPane, change the
   declaration:
        Rect r;
    to
        LongRect r;

6) (p. 349-350) Also in CDragPane.c, in the function DoClick, change the first
five lines from:
        Rect    r;
        Rect    endLocation;

        r = frame;
        EraseRect( &r );

        FrameToEnclR(&r);
    to these eight lines:
        Rect    r;
        Rect    endLocation;
        LongRect    longR;

        FrameToQDR( &frame, &r );
        EraseRect( &r );

        QDToLongRect(&r,&longR);
        FrameToEnclR(&longR);
        LongToQDRect( &longR, &r );

7) (p. 354) In the file CMouse.h, change the three lines:
        void        BeginTracking( Point *startPt );
        void        KeepTracking( Point *currPt, Point *prevPt, Point *startPt);
        void        EndTracking( Point *currPt, Point *prevPt, Point *startPt);
    to:
        void        BeginTracking( struct LongPt *startPt );
        void        KeepTracking( struct LongPt *currPt, struct LongPt *prevPt,
                                    struct LongPt *startPt );
        void        EndTracking( struct LongPt  *currPt, struct LongPt  *prevPt,
                                    struct LongPt  *startPt );

8) (p. 351) In the file CMouse.c, in the function IMouse(), change the
   declaration:
        Rect r;
    to
        LongRect r;

9) (p. 351) Also in the file CMouse.c, in the function IMouse(), change:
        theBounds = r;
    to
        LongToQDRect( &r, &theBounds );

10) (p. 351) Also in the file CMouse.c, in the function BeginTracking(), change
    the function declaration from:
        void CMouse::BeginTracking( Point *startPt )
    to
        void CMouse::BeginTracking( struct LongPt *startPt )

11) (p. 352-353) Also in the file CMouse.c, replace the function KeepTracking()
    with the following:

void CMouse::KeepTracking( struct LongPt *currPt, struct LongPt *prevPt,
                    struct LongPt *startPt )
{
    LongRect    r, f;
    Rect        shortR;
    long        curTicks;
    LongPt        startPosit, newPosit, cp, pp;
    RgnHandle    clipRgn;

    thePanorama->GetPosition( &startPosit );

    clipRgn = NewRgn();

    if ( thePanorama->AutoScroll( currPt )
            || ! EqualLongPt( currPt, prevPt ) )
    {
        thePanorama->GetPosition( &newPosit );

        GetClip( clipRgn );
        QDToLongRect( &((**clipRgn).rgnBBox), &r );
        OffsetLongRect( &r, startPosit.h - newPosit.h,
                startPosit.v - newPosit.v );

        thePanorama->GetFrame(&f);
        PinInRect(&f, (LongPt *)(&(r.top)));
        PinInRect(&f, (LongPt *)(&(r.bottom)));

        LongToQDRect( &r, &shortR );
        ClipRect( &shortR );

        shortR = theLocation;    /* Erase old gray rect */

        curTicks = TickCount();
        while ( curTicks == TickCount() ) ;
        FrameRect( &shortR );
        QDToLongRect( &shortR, &r );

        cp = *currPt;
        pp = *prevPt;
        QDToLongRect( &theBounds, &f );
        PinInRect(&f, &cp);
        PinInRect(&f, &pp);

        OffsetLongRect(&r, cp.h - pp.h, cp.v - pp.v);

        SetClip( clipRgn );

        curTicks = TickCount();
        while ( curTicks == TickCount() ) ;

        LongToQDRect( &r, &shortR );
        FrameRect( &shortR );    /* Draw new gray rect */
        theLocation = shortR;        /* update theLocation instance var */
    }
    DisposeRgn( clipRgn );
}


12) (p. 353) Also in the file CMouse.c, Replace the declaration of the function
    EndTracking() with:

void CMouse::EndTracking( struct LongPt  *currPt, struct LongPt  *prevPt,
                    struct LongPt  *startPt )


13) Add these three lines to the list of include files in the file
    CStarterDoc.c:

#include "TBUtilities.h"
#include "CWindow.h"
#include <Packages.h>

14) In the file CStarterDoc.c, in the function OpenFile(), replace the line:
        theError = theFile->Open(fsRdWrPerm);
    with the line
        theFile->Open(fsRdWrPerm);

15) In the file CStarterDoc.c, in the function OpenFile(), comment
    out each of the lines:
        gApplication->RequestMemory(FALSE, TRUE);
        theFile->ReadAll(&theData);
    and
        gApplication->RequestMemory(FALSE, FALSE);

16) (p. 343) In the file CStarterDoc.c, in the function BuildWindow(), change
    the line:
        Rect            panFrame;
    to
        LongRect        panFrame;

17) (p. 346) In the file CStarterPane.c, in the function DoDrag(), change the
    declaration:
        Rect        boundsRect;
    to
        LongRect        boundsRect;

18) (p. 346) In the file CStarterPane.c, in the function DoDrag(), add the new
    declaration:
        LongPt        longP;

19) (p. 346) In the file CStarterPane.c, in the function DoDrag(), change the
    line:
        TrackMouse( aMouseTask, p, &boundsRect );
    to
        QDToLongPt( p, &longP );
        TrackMouse( aMouseTask, &longP, &boundsRect );

ShowINIT.c:
1) (p. 397) Delete the line:
        #include <Color.h>




- -------------------------

From: [e-mail] (Wally Wedel)
Subject:  Think C 5.0 Changes for Vol II Mac C Primer
Date: 29 Jan 92 18:52:44 GMT
Organization: U S WEST Advanced Technologies

In article <[e-mail]> [e-mail]
(Jim Cook) writes:
> Because someone asked, I'm also published the changes for Vol II of the
> Macintosh Programming Primer.  The primer was published based on Think
4.0.
> The following will allow you to run the programs under Think 5.0.
> Send any questions to the book's author - I'm just the messanger!

But there's no address given for the authors!

In article <[e-mail]> [e-mail]
(Jim Cook) writes:
> FormEdit.c:
> 1) (p. 244) Replace #define MOVE_TO_FRONT from
>                 -1L
>         to
>                 (WindowPtr)-1L
>
> 2) (p. 251) In the function DoTEKey(), replace the line:
>                 tempStr[ i+1 ] = (*text)[ i ];
>         with the line:
>                 tempStr[ i+1 ] = (*(char **)text)[ i ];
>
> 3) (p. 257) In the function HandleEditChoice(), replace the line:
>                 tempStr[ i+1 ] = (*text)[ i ];
>         with the line:
>                 tempStr[ i+1 ] = (*(char **)text)[ i ];

2) and 3) look broken to me! They're trying to assign a CharsHandle to an
Str255.
                  tempStr[i+1] = (unsigned char)(*text)[i];

looks like a better bet! Their code compiles, but it doesn't appear to be right.


Wally Wedel
U S WEST Advanced Technologies
4001 Discovery Drive, Suite 390
Boulder, CO 80303
Internet: [e-mail]  AppleLink: D5100   Voice: 303-541-6052



---------------------------

From: [e-mail] (Raymond Degennaro)
Subject: Multi-thread packages
Date: 28 Jan 92 09:31:07 GMT
Organization: University of Southern California, Los Angeles, CA

I was wondering, has anybody out there written or knows of, a multi-thread
package for the mac?

Ray (DJ) DeGennaro
[e-mail]


--

Ray (DJ) DeGennaro II
[e-mail]



- -------------------------

From: [e-mail] (Patrick Logan)
Subject:  Multi-thread packages
Date: 31 Jan 92 16:09:47 GMT
Organization: Mentor Graphics Corporation

In article <[e-mail]> [e-mail] (Raymond Degennaro) writes:
   I was wondering, has anybody out there written or knows of, a multi-thread
   package for the mac?

I don't know if you are restricting yourself to C/C++. There are two
Scheme systems for the Mac that have multi-thread capabilities and
both have a C/Pascal interface.

(1) MacScheme+Toolsmith, commercial, ~$400

(2) Gambit Scheme, shareware, ~$20-40

Lightship Software, makers of MS+T, recently moved their HQ to the Bay
area. You can try to get a number for them there or here in Oregon. If
you have trouble, get back to me and I can get their new number. [I
have no connection other than being friends with one of the creators.]

Here's a note on getting Gambit...

================ Copied Note ================
You can get a copy of Gambit via anonymous ftp from
trex.iro.umontreal.ca (address 132.204.36.34).  Source code is
available as well as the binaries for a few machines:

   size    file
  829429  pub/gambit1.7.1/gambit1.7.1.tar.Z        Source for system
  925696  pub/gambit1.7.1/gsc1.7.1-gp1000          BBN GP1000 (compiler
  409600  pub/gambit1.7.1/gsi1.7.1-gp1000                      interpreter)
  878024  pub/gambit1.7.1/gsc1.7.1-hp7.0           HP9000/300, HPUX7.0
  365031  pub/gambit1.7.1/gsi1.7.1-hp7.0
  878063  pub/gambit1.7.1/gsc1.7.1-hp7.05          HP9000/300, HPUX7.05
  365070  pub/gambit1.7.1/gsi1.7.1-hp7.05
  919000  pub/gambit1.7.1/gsc1.7.1-next            NeXT
  400315  pub/gambit1.7.1/gsi1.7.1-next
  884736  pub/gambit1.7.1/gsc1.7.1-sun3            SUN3
  376832  pub/gambit1.7.1/gsi1.7.1-sun3
  200228  pub/gambit1.7.1/gambit1.7.1-mac.hqx      Macintosh version

Note: the Macintosh version only contains the interpreter.  The compiler,
linker and source code for the Macintosh version is available seperately
(check the "About..." dialog box in the interpreter).

Marc Feeley   -- [e-mail]

--
Patrick Logan, [e-mail],
Voice: [phone] x2907, FAX: [phone]
Mentor Graphics Corp., Bldg. C, 8005 SW Boeckman Rd., Wilsonville, OR 97070
I can't gete the .signature virus and I can't gete the .signature



- -------------------------

From: [e-mail] (Jerome Yvon Plun)
Subject:  Multi-thread packages
Date: 4 Feb 92 14:14:29 GMT
Organization: Washington University, St. Louis MO


  There is also the thread package developed by Michael Gough and described
in D E V E L O P.
  For more information, contact [e-mail]

  Jerome

Jerome Plun            []  Is it a crime to want something else?
[e-mail]    []  Is it a crime to believe in something different?
Washington University  []
St Louis, MO           []  "Smalltown England", New Model Army, Vengeance



---------------------------

From: [e-mail]
Subject: MacApp: IsObject isn't safe!
Date: 30 Jan 92 04:11:50 GMT
Organization: University of Otago, Dunedin, New Zealand

I think I have just discovered that the MacApp global IsObject function isn't
safe. I was using to test if a window I had added to the application free
window list was still around. This however causes occasional address error
crashes on 68000-based Macs as IsObject assumes it can go ahead and look for
class and method IDs once IsHandle returns OK. This turns out not to be true
sometimes in my case... A little more paranoia in IsObject would not go amiss -
have ther been any patches to it?


Michael(tm) Hamel, Computing Services Centre, University of Otago, New Zealand

BALDOCK (n.)
The sharp prong on the top of a tree stump where the tree has snapped off
before being completely sawn through.



- -------------------------

From: [e-mail] (Greg L. Anderson)
Subject:  MacApp: IsObject isn't safe!
Date: 30 Jan 92 18:13:16 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] writes:
>I think I have just discovered that the MacApp global IsObject function isn't
>safe. I was using to test if a window I had added to the application free
>window list was still around.

IsObject was not intended to be used in that capacity.  The statement

    foo = (TFoo*)DisposeIfObject((Handle)foo);

is only safe if foo is either a valid object or 'nil'.

True, IsObject could do more tests & be more robust than it currently
is, but code in the form

    bar = foo;
        foo = (TFoo*)DisposeIfObject((Handle)foo);
    // more allocations and stuff
    bar = (TFoo*)DisposeIfObject((Handle)bar);

will never work, because it is always possible that the memory that
foo formerly pointed to might be reused by some other object that
would pass any test that IsObject might perform on it.

The solution to your problem is to make sure that you remove your
window from any list it happens to be on when you free it.

--
=====================   ===========================   =====================
Greg Anderson           Apple Computer, Inc.            O    Ponnuki    O
Macintosh Bodhisattva   Developer Tools Engineering    O O  is  ideal  O O
[e-mail]       Apple Developer Suite           O     shape     O
=====================   ===========================   =====================



---------------------------

From: [e-mail] (Marcus Ziegler)
Subject: Disabling all interrupts via MacOS-routine ?
Date: 29 Jan 92 09:29:43 GMT
Organization: Technische Universitaet Muenchen, Germany


Does anyone know if there is a posibility to disable all Macintosh interrupts
(especially VBL) by using a Mac-OS routine and what are the problems that
might occur ?



- -------------------------

From: [e-mail] (Steve Christensen)
Subject:  Disabling all interrupts via MacOS-routine ?
Date: 1 Feb 92 01:46:49 GMT
Organization: Apple Computer Inc., Cupertino, CA

[e-mail] (Marcus Ziegler) writes:


>Does anyone know if there is a posibility to disable all Macintosh interrupts
>(especially VBL) by using a Mac-OS routine and what are the problems that
>might occur ?

Yes, you can disable all Macintosh interrupts at any time, but most everything
will stop working, specifically:

    keyboard and mouse
    time/date update
    VBLs, and so TickCount()
    slot interrupts (NuBus cards)
    floppy disk
    serial ports
    LocalTalk
    FileShare

I may have missed a few things, but at least these come to mind...

steve

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Steve Christensen            Never hit a man with glasses.
  [e-mail]            Hit him with a baseball bat.



---------------------------

From: [e-mail] (Dhanesh K Samarasan)
Subject: !Weird Behavior in Finder's "Get Info" Windows
Date: 29 Jan 92 10:13:55 GMT
Organization: Massachusetts Institute of Technology




Fellow net-nuts:

I just noticed something odd on two SCSI hard disks
connected to a Macintosh IIci running 7.0.1*.

For each and every file and folder on both hard disks, the
filename that is shown to the right of the icon in the "Get
Info" window behaves like a little button. On mouseDown,
the name is highlighted. On mouseUp, the name is
de-highlighted and then modified as follows:

        Original                Appears as
      ---------------------------------------
        Utilities               !Utiliti.es
        System Folder           !System.Fol
        ResEdit 2.1.1           !ResEdit.21
        HyperCard               !HyperCa.rd
        Text                    Text
          DD                    !DD
        EvenBetterBusError      !EvenBet.ter
        !Weird Problem          !!Weird.Pro

A second mouseClick on the name restores it to its rightful
value.

>From a cursory examination, I can't figure out the pattern
in the appearance of these pseudo-names. Clicking on any
other item in the "Get Info" window does not have the same
effect. DiskFirstAid, etc., do not find anything wrong with
the hard disks, and everything behaves normally in all
other respects.

The problem does not show up in the "Get Info" windows of
documents on mounted floppies or CDs. I'm not sure it has
any bearing, but the internal hard disk (MicroNet, Wren,
424Mb) is partitioned into six logical volumes, whereas the
external drive (iDS, 120 Mb) is not partitioned.

I haven't had the time to dive into the Tech Notes or IM to
see if there are any hints there as to what's going on; but
has anyone seen anything like this happen before?

Please advise.


--
Dhanesh

Replies, if any, to <[e-mail]>, please.
--



- -------------------------

From: [e-mail] (Matthias Ulrich Neeracher)
Subject:  !Weird Behavior in Finder's "Get Info" Windows
Date: 29 Jan 92 18:08:07 GMT
Organization: Integrated Systems Laboratory, ETH, Zurich

In article <[e-mail]> [e-mail] (Dhanesh K Samarasan) writes:
>Fellow net-nuts:
>
>I just noticed something odd on two SCSI hard disks
>connected to a Macintosh IIci running 7.0.1*.
>
>For each and every file and folder on both hard disks, the
>filename that is shown to the right of the icon in the "Get
>Info" window behaves like a little button. On mouseDown,
>the name is highlighted. On mouseUp, the name is
>de-highlighted and then modified as follows:
>
>        Original                Appears as
>      ---------------------------------------
>        Utilities               !Utiliti.es
>        System Folder           !System.Fol
>        ResEdit 2.1.1           !ResEdit.21
>        HyperCard               !HyperCa.rd
>        Text                    Text
>          DD                    !DD
>        EvenBetterBusError      !EvenBet.ter
>        !Weird Problem          !!Weird.Pro
>
>A second mouseClick on the name restores it to its rightful
>value.
>
>From a cursory examination, I can't figure out the pattern
>in the appearance of these pseudo-names.

Actually, it's quite easy: The name shown is MS-DOS compatible: If it was
modified from the original, a ! is prepended. Then, dots are removed and one
dot is inserted after 8 characters.

This is probably a feature for file sharing: It shows you the name of this
object if you make it available for sharing and mount it from an MS-DOS
compatible "computer".

I have seen this behaviour before under 7.0, but I don't remember on what it
depends (Maybe only for shared folders ?).

Hope this helps

Matthias

- ---
Matthias Neeracher                                   [e-mail]
 "You must have picked up that copy of Scarlett instead of Inside Mac
  when you tried to find the right call..." -- Keith Rollin



- -------------------------

From: [e-mail] (Ben Hekster)
Subject:  !Weird Behavior in Finder's "Get Info" Windows
Date: 29 Jan 92 15:08:17 GMT
Organization: University of Twente, Dept. of Computer Science

Hi, Dhanesh--

In article <[e-mail]> [e-mail] (Dhanesh K Samarasan) writes:
>For each and every file and folder on both hard disks, the
>filename that is shown to the right of the icon in the "Get
>Info" window behaves like a little button. On mouseDown,
>the name is highlighted. On mouseUp, the name is
>de-highlighted and then modified as follows:
>
>        Original                Appears as
>      ---------------------------------------
>        Utilities               !Utiliti.es
[...]

I think these are the "short file names" generated by File Sharing
to support the AppleTalk Filing Protocol on file systems that
can't handle the longer and less restricted Mac file system
names, such as MS-DOS.  I.e., "Utilities" would in fact appear
as "!Utiliti.es" on such a machine, the prefixed "!" indicating
that the file name had to be shortened.

    Look at what happens when you have two files with long and
almost identical names in the same folder, e.g. "verylongfilenamea"
and "verylongfilenameb".  The names are abbreviated (not simply
truncated) to remain distinguishable on foreign file systems.

>The problem does not show up in the "Get Info" windows of
>documents on mounted floppies or CDs. I'm not sure it has
>any bearing, but the internal hard disk (MicroNet, Wren,
>424Mb) is partitioned into six logical volumes, whereas the
>external drive (iDS, 120 Mb) is not partitioned.

My guess would be that you won't see the short file names on
volumes that are not being shared, or at all if file sharing
is off.

`Hackster'
--
Ben `Hackster' Hekster            | sigblock(sigmask(SIGFLAME));
[e-mail]            | "Here we are now, entertain us"



- -------------------------

From: [e-mail] (Nick Rothwell)
Subject:  !Weird Behavior in Finder's "Get Info" Windows
Date: 29 Jan 92 12:24:15 GMT
Organization: Friends of the Salter Duck

In article <[e-mail]> [e-mail] (Dhanesh K Samarasan) writes:

       Original                Appears as
     ---------------------------------------
       Utilities               !Utiliti.es
       System Folder           !System.Fol
       ResEdit 2.1.1           !ResEdit.21
       HyperCard               !HyperCa.rd
       Text                    Text
         DD                    !DD
       EvenBetterBusError      !EvenBet.ter
       !Weird Problem          !!Weird.Pro

Wild guess: something's translating the names into something
DOS-compatible. I think I've heard of this behaviour before, but
haven't tried it on my machine.

    Nick.
--
Nick Rothwell, LFCS, Edinburgh | "Chai ch t'chai ch't chnna chnna chnna ch'th
             [e-mail] |  Chai ch t'chai ch't chuth chena chann ch'tt
Mentation Consultancy Services |  Chie ch t'chie ch t'chaaa chn chattr chattr"
   [e-mail] |       -- Wavestation, V3 software, my dragon.



- -------------------------

From: [e-mail] (Dhanesh K Samarasan)
Subject:  !Weird Behavior in Finder's "Get Info" Windows
Date: 29 Jan 92 19:01:48 GMT
Organization: Massachusetts Institute of Technology

In article <[e-mail]> [e-mail] (Ben Hekster) writes:
[...]
>In article <[e-mail]> [e-mail] (Dhanesh K Samarasan) writes:
>>For each and every file and folder on both hard disks, the
>>filename that is shown to the right of the icon in the "Get
>>Info" window behaves like a little button. On mouseDown,
>>the name is highlighted. On mouseUp, the name is
>>de-highlighted and then modified as follows:
>>
>>        Original                Appears as
>>      ---------------------------------------
>>        Utilities               !Utiliti.es
>[...]
>
>I think these are the "short file names" generated by File Sharing
>to support the AppleTalk Filing Protocol on file systems that
>can't handle the longer and less restricted Mac file system
>names, such as MS-DOS.  I.e., "Utilities" would in fact appear
>as "!Utiliti.es" on such a machine, the prefixed "!" indicating
>that the file name had to be shortened.

This part I now understand (just goes to show, you can never know
too much about DOS).  Thanks to all who have responded.


>>The problem does not show up in the "Get Info" windows of
>>documents on mounted floppies or CDs. I'm not sure it has
>>any bearing, but the internal hard disk (MicroNet, Wren,
>>424Mb) is partitioned into six logical volumes, whereas the
>>external drive (iDS, 120 Mb) is not partitioned.
>
>My guess would be that you won't see the short file names on
>volumes that are not being shared, or at all if file sharing
>is off.

This part I still don't understand.  If filesharing is on and
foolish things happen to names of files on hard disks, why don't
the same foolish things happen to names of files on all floppies
that are mounted at the same time?



--
Dhanesh

Replies, if any, to <[e-mail]>, please.
--



- -------------------------

From: [e-mail] (Wade Williams)
Subject:  !Weird Behavior in Finder's "Get Info" Window
Date: 29 Jan 92 22:52:13 GMT
Organization: Auburn University

In article <[e-mail]> [e-mail] (Dhanesh
K Samarasan) writes:
>This part I still don't understand.  If filesharing is on and
>foolish things happen to names of files on hard disks, why don't
>the same foolish things happen to names of files on all floppies
>that are mounted at the same time?

Someone can correct me if I'm wrong, but I don't believe a floppy would be
available to FileSharing as a shared volume.


- -----------------------------------------------------------------------
Wade Williams                             "Any escape might help to smooth the
User Services Specialist            unattractive truth, but the suburbs
Academic Computing                     have no charms to soothe the restless
Auburn University                      dreams of youth." (N. Peart)
[e-mail]
- -----------------------------------------------------------------------



---------------------------

From: [e-mail] (Terje Rydland)
Subject: SPHIGS for Mac
Date: 29 Jan 92 10:22:14 GMT
Organization: Ifi, University of Trondheim / AVH

I think I saw a similar question a few weeks back, but I didn't see
any replies. So I ask the question again:

    Does anybody know of a SPHIGS-implementation for Mac?

Terje



- -------------------------

From: [e-mail] (Thomas Alan Akins)
Subject:  SPHIGS for Mac
Organization: /local/lib/rn/organization
Date: Wed, 29 Jan 1992 23:48:21 GMT

The second to the last page of _the_ graphics text, _Computer Graphics:
Priciples and Practice_ 2nd ed., has an order form for SRGP/SPHIGS for the
Macintosh.  Here's the order info:

    Macintosh version
    0-201-54701-5  $14.95

    Addison-Wesley Publishing Company
    Attn: Order Department
    Reading, MA 01867-9984


There is a paragraph above this info that states:

    "To order, photocopy and complete the form below...."

So, if you don't have a copy of the book, check it out somewhere and photocopy
the back page and send it in.

Previous replies to similar questions have posted various ftp sites as well.
                            _    _
--
*                                            Alan Akins                      *
*       "I could say 'addition'              [e-mail]            *
*        when I mean ... 'basketball.'"      University of Oregon            *
*                        - E. Tick           Department of Computer Science  *



- -------------------------

From: [e-mail] (Donald Sturgeon)
Subject:  SPHIGS for Mac
Date: 30 Jan 92 13:11:39 GMT
Organization: Glasgow University Computing Science Dept.

There is a SPHIGS software package for the mac mentioned in:

    "Computer Graphics: Principles and Practice"

    by Foley, van Dam, Feiner and Hughes.
    Published by Addison Wesley.

The package is available from Addison Wesley.
They quote a price of $14.95, but you need Think C or Think Pascal to use it.

The book also mentions versions for Unix and PC.



---------------------------

From: [e-mail] (Lars Sundstr|m)
Subject: Format of icm#, icm4, icm8 icon resources
Date: 29 Jan 92 13:22:53 GMT
Organization: Applied Electronics, Lund University, Lund, Sweden


According to Technical Note #306 new (and even smaller than "icsX") icons
will be  supported in the future. However, nothing is mentioned about
the format of these icons (icm#, icm4 and icm8).

Does anyone know anything about these formats?

--
Lars Sundstrom, Lund University, Department of Applied Electronics,
Box 118, S-221 00 Lund, Sweden Phone: [phone] Fax:[phone]
Internet: [e-mail]
--



- -------------------------

From: [e-mail] (Ross Brown)
Subject:  Format of icm#, icm4, icm8 icon resources
Organization: Bell-Northern Research
Date: Sat, 1 Feb 92 02:09:00 GMT

In article <[e-mail]> [e-mail] (Lars Sundstr|m)
writes:
>
>According to Technical Note #306 new (and even smaller than "icsX") icons
>will be  supported in the future. However, nothing is mentioned about
>the format of these icons (icm#, icm4 and icm8).
>
>Does anyone know anything about these formats?

There are templates for these new formats in the MPW 3.2 Rez distribution.
What I found surprising when I added 'icm#', 'icm4', and 'icm8' resources to my
application was that while they are nominally 12x12 pixels, you have to allow
for 4 blank columns at the right side in your Rez source (actually 12 rows by
16 columns), and then when you use PlotIconID to plot them, you have to make
sure you plot into a 12x16 rectangle (or one with that aspect ratio), or your
12x12 image comes out squished.

Here's an excerpt from my code for plotting an icon into a small,
variably-sized window.  Note the kludge which stretches the rectangle if the
code thinks that PlotIconID will use an 'icm?' resource.

    theRect = qd.thePort->portRect;
    if( theRect.right - theRect.left <= 12 && theRect.bottom - theRect.top <= 12 )
        theRect.right += ( theRect.right - theRect.left ) * ( 16 - 12 ) / 12;
    (void) PlotIconID( &theRect, align, transform, theResID );

Ross Brown
Bell-Northern Research Ltd.
Ottawa, Ontario, Canada
[e-mail]
Opinions expressed do not necessarily represent those of BNR.



---------------------------

From: [e-mail] (Michael J. Tarr)
Subject: CacheOut
Date: 29 Jan 92 15:26:07 GMT
Organization: Department of Psychology, Yale University


The most recent MacUser describes a utility called CacheOut by HandOff
corp. that automagically turns the quadra cache on and off with
applications. It is on compuserve in ZiffNet/Mac in library 3 of
download and support forum, file CACHEO.CPT -- Could someone who has
compuserve post this?

Mike Tarr



- -------------------------

From: [e-mail] (Steve Howell)
Subject:  CacheOut
Date: 30 Jan 92 14:59:31 GMT
Organization: University of Tasmania, Australia.

>The most recent MacUser describes a utility called CacheOut by HandOff
>corp. that automagically turns the quadra cache on and off with
>applications. It is on compuserve in ZiffNet/Mac in library 3 of

  Or, you can use "compatibility", a program that will automatically
disable the Quadra's cache if certain (user-selectable) applications are
executed. It's archived as "quadra-auto-cache" and is available at
sumex-aim.stanford.edu in the info-mac/cp directory.



---------------------------

From: [e-mail] (Jonathan Greenfield)
Subject: Old (strange) finder icon masks
Organization: CIS Dept., Syracuse University
Date: Wed, 29 Jan 92 11:36:47 EST


Is anybody very familiar with old icon masks?

I have written an application that, at one point, copies an icon family from
a desktop database into a file as a (finder) custom icon family.

This has worked fine, except for one example (among the ones I have tried):
StuntCopter.

The StuntCopter icon did not display properly, so I opened up the file
(using ResEdit) and found that the icon mask did not cover the entire icon.
To check and see if there was an error in the copying process, I opened up
StuntCopter, as well a file that used the StuntCopter icon--pasted in using
the Finder's "get Info" window.  All of the masks were identical.

The Finder, apparently, recognizes that the mask is strange, for the
original application file, and the manually copied (within the finder)
custom icon resource, and displays them properly (as though there were a
proper mask).  For the automatically copied file, however, the finder does
not adjust for the strange mask, and as a result, displays the icon improperly.

Does anybody know what's going on, or how to deal with this?

--
greeny                                           [e-mail]

"What's the difference between an orange?"



- -------------------------

From: [e-mail] (Jamie R. McCarthy)
Subject:  Old (strange) finder icon masks
Date: 29 Jan 92 19:35:00 GMT
Organization: Kalamazoo College

[e-mail] (Jonathan Greenfield) writes:
>
>I have written an application that, at one point, copies an icon family from
>a desktop database into a file as a (finder) custom icon family.
>This has worked fine, except for one example (among the ones I have tried):
>StuntCopter.
>The StuntCopter icon did not display properly, so I opened up the file
>(using ResEdit) and found that the icon mask did not cover the entire icon.
>
>Does anybody know what's going on, or how to deal with this?

I can guess.  Older finders (before 6?) used to XOR the mask with the
data to get the "selected" view of the icon.  Lots of old programs used
this feature to completely change their icon around--Red Ryder, for
example, would change from its ugly two Macs, phones, telephone wires,
disks, and Lord knows what else, to a cool silhouette of a guy on
horseback.

Of course, the Finder hasn't done this for many years, but the programs
(and their icons) don't know that.
--
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Kzoo randomly kills all my mail;  if I don't acknowledge, try resending.



- -------------------------

From: [e-mail] (Jonathan Greenfield)
Subject:  Old (strange) finder icon masks
Date: 29 Jan 92 22:25:52 GMT
Organization: CIS Dept., Syracuse University

In article <[e-mail]> [e-mail] (Jamie R. McCarthy) writes:
>
>I can guess.  Older finders (before 6?) used to XOR the mask with the
>data to get the "selected" view of the icon.  Lots of old programs used
>this feature to completely change their icon around--Red Ryder, for
>example, would change from its ugly two Macs, phones, telephone wires,
>disks, and Lord knows what else, to a cool silhouette of a guy on
>horseback.
>
>Of course, the Finder hasn't done this for many years, but the programs
>(and their icons) don't know that.

This much I guessed.  The question is, why does the Finder properly handle
these icons for the original apps/manually copied custom icons, but not
for my automatically copied icons?

Is there some kind of flag or attribute that has to be set?

--
greeny                                           [e-mail]

"What's the difference between an orange?"



---------------------------

End of C.S.M.P. Digest
**********************